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@ Metiiod and apparatus for operating a computer-based file system. 

@ A computer-based file system includes files 
which may have one or more data streams 
associated therewith. The files are accessed 
using a base name and tiie associated data 
stream(s) are accessed using a prefix and/or a 
suffix of the base name. For example, the base 
name may be used to select a data file while the 
prefix and/or suffix may be used to access data 
streams which, illustratively, may include Infor- 
mation used by the file system in the processing 
of the data file. Using this file naming structure 
enables the file system to handle the base name 
file and Its assodated data sb^ams togetiier as 
one file using the standard file commands. 
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Cross-Reference to Related Application 

Related subject matter is disclosed in my other 
application filed concurrently herewith and assigned 
to the same assignee hereof: U. S. patent application 
Serial No.07/735.d93 "Method and Apparatus for Ac- 
cessing a Computer-Based File System." 

Technical Field 

The present invention relates to a computer sys- 
tem and, more particularly, to the accessing of a file 
system thereof. 

Background of the Invention 

Operating systems exist today which have a file 
system which enables the user to access one or more 
data streams of a file (where a data stream is a se- 
quence of data bytes). In one example, the Apple® 
Macintosh® Hierarchical File System, two data 
streams are supported per file: one stream is called 
the data fork, and the other is called the resource fork 
(Apple and Macintosh are registered trademarks of 
Apple Computer, Inc.). A programmer selects a par- 
ticular stream via a combination of a file name and a 
bit parameter to open a stream and then uses conven- 
tional file system calls (e.g., read (), write Q, lseek(), 
etc.) to operate on that data stream. Undesirably, if a 
newfork (data stream) is added to the file system, and 
consequently a new bit parameter required, existing 
programs must be rewritten to permit access to the 
new data stream. Such program rewrites are a costly 
overhead for the user. 

The OS/2® operating system available from IBM, 
is another hierarchical file system (OS/2 is a regis- 
tered trademark of International Business Machines 
Corporation). The High Performance File System of- 
fered by OS/2 also supports two data streams per file: 
one stream contains the normal file data, while the 
other stream contains extended attribute information 
which has been associated with this file. In OS/2, dif- 
ferent operating system calls are used to manipulate 
each of the two data streams. Such an arrangement 
requires a separate set of operating system calls 
when a new data stream Is added. Undesirably, exist- 
ing programs must be rewritten when new operating 
system calls are added to the OS/2 repertoire. 

What is desired is a technique which enables an 
operating system to access an ever-Increasing num- 
ber of data streams of any file in a manner which is 
compatible with existing operating system calls and 
commands, thereby eliminating the need to rewrite 
existing programs. 

Summary of the Invention 

In accordance with the apparatus and method of 



the present invention, a file system accesses previ- 
ously stored data files using a file name defined as In- 
cluding a base name and at least one appended seg- 
ment The appended segment(s) may be a pref be, a 

5 suff be, or both a pref be and suffix of the base name. 
When a file access request is received, the file name 
is parsed Into a base name and a segment(s). The 
base name is used to search the stored files to obtain 
a desired file. An appended segment is then used to 

10 select for access a data stream associated with the 
desired base name file. The present invention thus 
enables a file system to access the data streams of 
any file in a manner which Is compatible with existing 
operating system calls and user level commands 

15 thereby eliminating the need to rewrite existing pro- 
grams. 

According to other features of the invention, an 
appended segment may be used to access attributes 
of a stored file, or to designate an operating system 
20 to be used to process a particular data stream. 

Brief Description of the Drawing 

In the drawing 

25 FIG. 1 illustrates a block diagram of a computer 
and its operating system which is useful In de- 
scribing the operation of the present invention; 
FIG. 2 shows the logical and physical structure of 
a file and a file system; 

30 FIG. 3 defines various terms useful In describing 
the present Invention; 

FIGs. 4 and 5 illustrate a flow chart describing va- 
rious operating features of the present inventton; 
and 

35 FIG. 6 is a table illustrating examples of various 
prefbces and suff bees used by the present inven- 
tion. 

High Level Description 

40 

In the following description, each item or block of 
each figure has a reference designation associated 
therewith, the first number of which refers to thef igure 
in which that Item Is first located (e.g., 110 Is located 

45 in FIG. 1 and step 501 is located In FIG. 5). 

FIG. 1 depicts a computer based file system 100 
which operates under control of a UNIX® operating 
system 110, shown using a high-level architecture 
layer diagram. (UNIX Is a registered trademark of 

50 UNIX System Laboratories, Inc. (hereinafter USL)). 
The layer diagram includes a user level 120, a kernel 
level 130, and a hardware level 140. The user level 

120 Interfaces to a user 101 enabling access to the 
file system 100 to obtain the desired file stored in 

55 memory (e.g., disk 1 80). 

The user level 120 includes the user programs 

121 and libraries 122. The hardware level 140 pro- 
vides the operating system 110 with basic services 
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needed by computer 100. The kernel level 130 inter- 
acts directly with the hardware level 140 providing 
conrunon services to user level 120 programs and in- 
sulating them from hardware idiosyncrasies. Viewing 
the system as a set of layers, the operating system is 5 
commonly called the system kernel 130, or Just the 
kernel, emphasizing its isolation from user programs. 
Because user programs are independent of the un- 
derlying hardware, it is easy to move them between 
UNIX systems running on different hardware. The io 
general description of the well-known operation of a 
UNIX operating system Is derived from Chapter 2 of 
the book entitled The Design of the UNIX Operating 
System" by Maurice J. Bach. 

The system call Interface 1 31 represents the bor- is 
der between user level 120 (user programs 121 and 
program libraries 122) and the kernel level 130. Sys- 
tem call interface converts user program calls into 
UNIX system calls. System calls look like ordinary 
function calls in C programs, and libraries map these 20 
function calls to the primitives needed to enter the op- 
erating system in a well-known manner. The set of 
system calls includes those that Interact with the file 
system driver 132 and those that Interact with the 
process control subsystems 1 33. The file system driv- 25 
er 1 32 manages files, allocating file space, controlling 
access to files, and retrieving data for users. Process- 
es interact with the file system driver 132 via a spe- 
cific set of system calls, such as open (to open a file 
for reading or writing), close, read, write, stat (query 30 
the attributes of a file), chown (change the record of 
who owns the file) and chmod (change the access 
permissions of a file). The file system driver 132 ac- 
cesses file data using a buffer 1 36 that regulates data 
flow between the kernel and secondary storage de- 35 
vtoes. The buffering mechanism interacts with block 
I/O device drivers 137 to initiate data transfer to and 
from the kernel. Device drivers 134 are the kernel 
modules that control the operation of peripheral devic- 
es. Block I/O devices 141 are random access storage 40 
devices; alternath^ely, their device drivers 137 make 
them appear to be random access storage devices to 
the rest of the system. For example, a tape driver may 
allow the kernel to treat a tape unit as a random ac- 
cess storage device. The file system also interacts dl- 45 
rectiy with "raw" or character t/O device drivers 138 
without the intervention of a buffering mechanism. 
Raw devices, sometimes called character I/O devices 
142, include all devices that are not block devices. 

The process control subsystem 133 Is responsi- 50 
ble for process synchronization, interprocess commu- 
nication, memory management, and process sched- 
uling. The file system driver 1 32 and the process con- 
trol subsystem 133 interact when loading a file into 
memory for execution. The process control subsys- 55 
tem 133 reads executable flies into memory before 
executing them. 

Some of the system calls for controlling process- 
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es include the following: fork (create a new process), 
exec (overlay the image of a program onto the run- 
ning process), exit (finish executing a process), wait 
(synchronize process execution with the exit of a pre- 
viously forked process), brk (control the size of menv 
ory allocated to a process), and signal (control proc- 
ess response to extraordinary events). 

As previously noted, file system 100 enables the 
user to access files stored on disk 180. A "file" is best 
viewed as a logical information object which may in- 
clude one or more data streams and which has an 
owner and permissions and other attributes, and one 
or more file names. A data stream is best viewed as 
an independent sequence of data bytes that can grow 
or shrink independent of any other data streams on 
the machine. Hence, the following are file operations: 
rename, link, change ownership, change group own- 
ership, and change mode. The following are data 
stream operations: read, write, and lock (a portion of 
a data stream). 

With joint reference to FIGs. 1, 2 and 3 we de- 
scribe an overview of a file system. Every file is 
named by one or more path names, 31 0. A path name, 
as shown in 310, includes file names (e.g., home) 
separated by delimiters (/). The internal representa- 
tion of a file is gh^en by an inode, which contains a de- 
scription of the disk layout of the file data and other 
information such as the file owner, access permis- 
sions, and access times. The term inode is a contrac- 
tion of the term index node and is commonly used in 
literature on the UNIX system. Every file has one in- 
ode, but it may have several path names, all of which 
map Into the inode. Each path name is called a link. 
When a process refers to a file by path name, the ker- 
nel parses the path name one f De name component 
at a time, checks that the process has permission to 
search the directories in the path, and eventually re- 
trieves the Inode for the file. For example, if a process 
makes the call "open (/home/jqp)" the kernel retrieves 
the inode for '/home/jqp". As shown by 31 5 a "file sys- 
tem tree" for a full path name starts with a slash char- 
acter ("/") and specifies that the path name is relative 
to the "root" of the file system tree. Following the 
branches that lead to successive component names 
of the path name "/home/jqp/2@memolrs" designates 
a full path name while "home/2@memoirs" does not. 
A path name does not have to start from root but can 
be designated relative to the "current directory" of an 
executing process by omitting the initial slash in the 
path name. Thus, starting from current directory 
"/home", the path name "Bin" designates the file 
whose full path name is "/home/Bin". 

In accordance with the present Invention, the file 
name 320 or purported file name may be considered 
to Include a prefix, a base name and a suffix and the 
prefix and suff be can be used to select alternate data 
streams of the particular file (file system object) des- 
ignated by base name. A base name 330, as shown 
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in FIG. 3, may be a conventional "physical" file name 
331, (typically stored in a directory) or a prescribed 
syntax 332 or a non-substring-based name 333 which 
are described in my previously referenced co-pending 
patent application which is Incorporated herein by ref- 
erence. 

When a process creates a new file, the file sys- 
tem driver 132 assigns it an unused Inode. Inodes are 
stored in a section 223 of the physical file system 220, 
as will be described shortly, but the file system driver 
132 reads them into an in-core-memory Inode table 
when manipulating files. The UNIX system typically 
keeps regular files and directories on block devices 
such as disks. An installation may have several phys- 
ical disk units each containing one or more file sys- 
tems. A file system 220 is organized as a sequence 
of logical blocks, each containing 512, 1024, 2048, or 
any convenient multiple of 512 bytes, depending on 
the system implementation. Multiples of 512 are used 
by convention and there Is no intrinsic reason to use 
512 byte blocks. 

A physical f Oe system may have the physical 
structure Illustrated by 220 of FIG. 2. The boot block 
221 (only on some file systems) occupies the begin- 
ning of a file system, typically the first sector, and may 
contain the bootstrap code that is read Into the ma- 
chine to boot or initialize the operating system. Al- 
though only one boot block 221 is needed to boot the 
system, every file system may have a (possibly emp- 
ty) boot block. The super block 222 describes the 
state of a file system-how large it is, how many files 
it can store, where to find firee space on the file sys- 
tem, and other information. The inode list 223 is a list 
of inodes that follows the super block In the file sys- 
tem. Administrators specify the size of the inode list 
223 when configuring a file system. The file system 
driver 132 references inodes by index into the inode 
list 223. One inode Is the root inode of the file system: 
It is the Inode by which the root directory structure of 
the file system is accessible after execution of the 
mount system cail. The data blocks 224 start at the 
end of the inode list and hold the contents of data 
streams (i.e., file data). An allocated data block con- 
tains the actual data of a data stream of a file and can 
belong to one and only one file in the file system. 

The operation of the present invention will be de- 
scribed as utilized in an Enhanced File System (EFS) 
implemented on a UNIX system using a virtual file 
system. Some UNIX systems use a Virtual File Sys- 
tem (VFS) concept to organize all file system opera- 
tions. Although the present invention does not require 
a VFS mechanism, VFS provides a convenient con- 
ceptual model to explain the invention. VFS Is a 
merge of the System V File System Switch (FSS) and 
the SUN OS VFS mechanism. It is important to note 
that user programs will be unaffected by the SVR4.0 
VFS architecture. 

VFS provides a file system type independent in- 



terface to programs and users while allowing each 
particular f De system to process file system opera- 
tions in their own manner. File system type dependent 
kernel routines do the work specific to the type. 
5 A key strength of VFS is that it allows new file sys- 

tem types to be defined and implemented by third- 
party software houses. The set of kernel interfaces 
that constitute VFS are available in a VFS file system 
type writers' guide available from USL 
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General Description 



The present invention permits access to each of 
these data streams in a manner that is compatible 

1$ with existing UNIX systems via special fSe names. 
This special file naming scheme uses a fOe name 
which includes a base name and a prefix, a suffix or 
both. Additionally, the present invention can be util- 
ized with any operating system which accesses files 

20 by file name. 

An overview of the capabilities of the present In- 
vention will, illustratively, be described with reference 
to a file name comprising only a prefix and a base 
name. Obviously, a file name which uses a base 

25 name and suff be combination or a prefix, base name 
and suff be combination could also be used to obtain 
the same capabilities. 

The present invention, as utilized in an Enhanced 
File System (EFS), uses a file name prefix string to 

30 permit access to non-defeult data streams. For exam- 
ple, the defeult EFS configuration may operate as fol- 
lows: the file name "foo" accesses the default (0th) 
stream of file "foo". That is, the absence of a prefix in 
front of 'Yoo" results In the access of the default or null 

35 (0th) data stream, the file name " 1@foo" accesses 
the 1st stream of file "foo", the file name "2@foo" ac- 
cesses the 2nd stream of file "foo," the file name 
"SQfoo" accesses the 3rd stream of file "foo" and so 
on. This prefbdng scheme permits all streams to be 

40 manipulated by existing UNIX applications (e.g., vl(1), 
sh(1)) and services (e.g., Remote File System 
(RFS)). 

One use of these multiple data streams can be to 
support multiple client operating systems. For exam- 

45 pie, both the Macintosh HFS and OS/2's High- 
Performance File System (HPFS) support two data 
strean^ per file. In both the Macintosh HFS and OS/2 
HPFS the resource fork and extended attribute data 
are used to hold data such as icons, fonts, history, 

60 subject information, application specific configura- 
tion parameters, etc. 

Utilizing the present Invention, a UNIX-based file 
system may support file servers for heterogeneous 
client machines (e.g., Macintosh and OS/2) as fbl- 

55 lows: stream 0, e.g., 212, contains the shared (regu- 
lar) data; stream 1, e.g., 213, contains the Macintosh 
Resource fork; stream 2, e.g., 214, may contain the 
OS/2 extended attribute data, and other streanns; e.g., 
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215 may be used for secondary data or extended at- 
tributes for other operating systems, sucli as the UNIX 
system. 

The file system 132 Iceeps trade of each of the 
streams, and assures that they are each independent 
in the way that they are accessed, and yet consistent 
for file operations {e.g., rename, change owner- 
ship...). 

Detailed Description 
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With reference to the layer diagram of FIG. 1 we 
now provide a more detailed operating description of 
the present invention. 

With joint reference to FiGs. 1 and 4 we describe is 
the detailed operation of the present invention. The 
present invention is implemented to perform a file 
system-specific lookup feature as part of the standard 
loolcup path name feature which occurs during a con- 
version of a path name to a vnode. The present inven- 20 
tion permits a single inode to contain multiple data 
streams, so the term vnode shall be used to refer to 
the virtual node that is associated with a particular 
data stream. Hence, with four data streams per file, 
there will be four vnodes per inode. Unless otherwise 25 
stated, a vnode refers to the 0th data stream of a file. 

The initial access to a file is by Its path name, as 
in the open, chdir (change directory), or llnic system 
calls. Because the kernel 130 works internally with 
vnodes rather than with path names, it converts the 30 
path names to vnodes to access files. An algorithm of 
the UNIX system kernel parses the path name one file 
name component at a time, converting each compo- 
nent into a vnode based on its name and the directory 
being searched, and eventually returns the vnode of 35 
the input path name. 

The steps 401-425 and steps 429-439 illustrate 
the existing steps of the path name to vnode conver- 
sion which are briefly described so that the detailed 
operation of the present inventbn (FIG. 5) can be ex- 40 
plained in a typical operating context. 

When a user program 121 makes a process call, 
e.g., open (path name, open vnode flag), the operat- 
ing system kernel (hereinafter kernel) 130 generates 
the command vn_open(name. seg, file mode, create 45 
mode, vpp, crwhy) in step 401. The command vn_open 
performs permission checks and opens a file by 
name, returning a pointer to the resulting vnode. In the 
command vn_open the parameter name contains the 
path name; seg is the address space the file name is so 
In. either user space or kernel space; file mode is the 
open mode; create mode contains the permission bits 
if the file is to be created; vpp is a pointer to a vnode 
pointer for the result; and crwhy is the reason why this 
routine is called, it is defined if and only if file mode 55 
has the Fcreate bit set. 

In step 402 a file name is received from the user 
program 1 21 . In step 403, the kernel 1 30 checks if the 



Fcreate bit is set If so, then in step 405 a conrunand 
vn_create( ) is generated In the conventional manner. 
The command of vn_create indicates to the kernel 
130 that the process call wishes to create a new file, 
an operation which Is well-known and not important to 
an understanding of the present invention. 

If the Fcreate bit is not set then in step 407 the 
path name Is checked to determine if one exists. In 
our example, recall the path name is 7home/jqp/ 
2@memoirs". if path name was a null then In step 409 
an "entry not found" error Is returned to the system 
user. 

If path name Is nota null then in step411 ttie trail- 
ing delimiters or slashes in the path name are elimin- 
ated. (Note our example has no trailing slashes after 
"memoirs"). In step 413, If ttie first character of 'na- 
me' is a T character (indicating a path name starting 
at root), then the working directory is set to root, 
ottierwise the working directory is set to the current 
directory, in step 415. it is determined whettier the 
working directory is a directory. If not. then in step 41 7 
a "not in directory" error is returned to the user. If 
working directory is a directory, then in step 419 the 
leading file name component (i.e., "home" in our ex- 
ample) is stripped off tiie path name. 

In step 421, tiie stripped off file name component 
"home" is compared to If equivalent, then In step 
423 tfie system will reference tiie current working dh 
rectory and then control returns to step 415. If file 
name component is not ". " then in step 425 it is conr>- 
pared to "..". If equivalent to tiien In step 427 the 
parent of the current working directory is referenced 
and control returns to step 415. Otherwise, step 427, 
the file systenvspeclf ic lookup feature of the present 
invention, as illustrated in FIG. 5. is performed on the 
stripped-off file name "home". 

The file system-specific lookup feature will be de- 
scribed In more detail in a later paragraph, but suffice 
it to say tiiat the stripped-off file name "home" In- 
cludes no prefix or suffix (as shown by 321). Hence, 
after the steps of FIG. 5 are performed on the file 
name "home" it returns to step 429 with a vnode ref- 
erence to access tiie file object of the file "home". If 
no vnode reference was found then an error is re- 
turned to tiie user in step 431 . Ottierwise, in step 433, 
the system checks if the vnode reference refers to a 
data object which Is a symbolic link. If so, then in step 
435. the contents of the link are placed at tiie front of 
tiie remaining path name. Otherwise, in step 437 ttie 
system determines whether there are more file name 
components in the path name, if no more file name 
components then in step 439 control is returned witti 
a vnode reference to ttie data object. If more file name 
components exist then control Is returned to step 415 
for further processing. 

With reference to FIG. 5 we now describe the 
present invention, as illustratively embodied, as a file 
system-epedflc lookup feature. We describe ttie 
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processing of the file name "home" of our example 
path name °/home/iqp/2@memoirs". In step 501 the 
requester's execute permission In the current direc- 
tory Is checked In the standard way. If permission 
does not exist an access error is returned to the user 5 
in step 502. If permission exists, then In step 503. a 
check is made to determine If a prefix or suffix exists. 
Recall from FIG. 3 that file name 320 may include 
three segments, a prefix, a base name and a suffix. 
Some possible prefixes and suffixes are listed in Ta- io 
bleeoOof FIG. 6which is stored as partof super block 
222 of FIG. 2. If no pref be or suff be is found then proc- 
essing continues to step 507. Recall in our example 
file name "home" no prefix or suffix Is used. Since the 
file name "home" does not contain any of the possible is 
pref bees listed in Table 600 of FIG. 6, in step 505, the 
base name is equivalent to the file name "home" and 
the current directory is searched for the base name. 

If, however, a prefbc or suffix match is found in Ta- 
ble 600, a software flag Is set indicating respectively 20 
that a prefbc and/or suff be match exists. Basically, a 
prefbc or suffbc match is determined by comparing 
each prefix and suffbc located in Table 600 with the 
file name. Prefbces and suffixes are typically stored 
in the super block of the file system. 25 

In step 505 any prefbc or suffbc Is stripped from the 
purported file name to produce the 'base name". In 
step 507. the directory Is searched using the "base 
name" resulting when the file name is stripped of any 
prefix or suffix. In step 509 if a "base name" is found 30 
In the directory, then in step 511 the prefix or suffbc 
flags are checked. If no prefix or suffix is found then 
in step 513 control returns the vnode associated with 
the 0th data stream base name. Thus, for our exam- 
ple, for file name "home", the vnode for the 0th data 35 
stream of the "home" file object would be returned to 
step 429 of FIG. 4 for continued processing in the pre- 
viously described manner. 

If a prefbc or suffbc was found in the file name, 
then the feature returns the success status along with 40 
the reference vnode of the selected data stream of the 
object base name. 

Thus, in our example, path name "/home/jqp/ 
2@memolrs" after the file name "home" is processed 
via steps 501, 503, 507, 509. 511, 513 and then by 45 
steps 429. 433 and 437. Subsequently, in step 415, 
419, 421, 425 and 427 the file name "jqp" is process- 
ed. Since "jqp" has no prefix or suffix, It is processed 
in the same manner as "home", i.e., by steps 501, 503, 
507, 509, 511, 513 and then by steps 429, 433 and so 
437. After processing file names "home" and "jqp" the 
file name ''2@mennolrs" is processed In a similar man- 
ner. Thus, steps 415, 419. 421, 425 and 427 are per- 
formed. However, since "2@ memoirs" has a prefbc, 
i.e.. "2@" step 505 is performed and a prefbc flag Is 55 
set. Thus, processing proceeds from step 501, 503, 
505, 507, 509 51 1 to step 51 5. In step 51 5, the feature 
returns the success along with the reference vnode of 



the data sb^am specified by prefbc "2@" for the file 
named "memoir". For example, the data stream spe- 
cified by prefbc "2@" may specify fonts or icons that 
should be utilized with the text of the "memoirs" file. 
The various types and uses of prefixes and suffixes 
are described In a later paragraph. 

With reference to Table 600 of FIG. 6, we briefly 
describe examples of some of the various configured 
prefbces and suffixes that can be utilized by the pres- 
ent Invention, if the base name is referred to as the 
physical file name the combination of the <prefbc> 
<base name> <suff bo can be referred to as a virtual 
file name where each of the virtual file names share 
the data with the base name file. One example of an 
application of the virtual file name capability would be 
to simulate on a UNIX system the Macintosh (MAC) 
file name sfa-ucture. I.e., "file name, biT where bit in- 
dicates whether the file is the data file or resource file. 
According to the present invention, a prefix or suffbc 
would identify the bit informatkm, e.g., <blt> <file 
name> or <f iie name> <bit>. respectively, to the UNIX 
system. Another application would be to provide an 
OS/2 attribute capability to a UNIX system, in OS/2 a 
file name is followed by a prefbc or suffix thereby per- 
mitting the extended attribute data to be accessed via 
standard file system primitives, e.g., open, read, 
write, dose, lock. 

Note, the examples described below as a prefix 
may also be utilized as a suffbc. The prefbc types of Ta- 
ble 600 may be represented by one or nnore digits, 
characters or symbols. For example, the prefbc "1@" 
may represent "extended atbibutes" of an OS/2 sys- 
tem while prefix "2@ " may represent the resource file 
of a Macintosh system. The prefbc "unx@" may rep- 
resent a UNIX system extended attribute capability. 
Other examples of prefixes may Include "oid@" to sig- 
nify an older version of the base name file, while 
"Cl@" may represent the compiled or interpreted ver- 
sion of the base name file. 

While the present inventton has been described 
as accessing data of a previously-stored file, another 
application may be to access general characteristics 
or attributes of that data. These characteristics were 
not necessarily stored explicitly, but rather were conrv 
puted or tested at run-time. For example, a total-file- 
size stream could be added that, when opened and 
read, returned the character representation of the to- 
tal number of bytes of storage used by all of a file's 
data streams. 

Thus, using my file naming convention a user can 
access any file 'attribute(s)' as a file -i.e., using 
openO. readO, writeQ, dose-that is associated with a 
real file. 'Attributes' Indude existing atbibutes such 
as: owner, group, mode, eto., as well as new or en- 
hanced attributes such as: file type, subject or sunrv 
mary of contents, history, relationship between this 
object and any other object, icons, conf iguratton data, 
a complied/interpreted form of the file, application-or 
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f iie-type-specif ic data [e.g., use total size as an exam- 
ple of virtual data stream, virtual data stream create 
when accessed.] 

In the above attribute list the compiled/interpreted 
form may be a virtual characteristic accessible as a s 
virtual file. The other attributes listed are generally 
physical characteristics accessible as a physical data 
stream. 

Thus, more particularly, my file naming conven- 
tion may be used to access any file attributes (descri- io 
bed above) via a file sharing mechanism or protocol 
such as: Network FQe System, Remote File System, 
Andrew File System, etc using our file naming con- 
vention to permit an extensible number of secondary 
streams to be associated with a file in a compatible is 
fashion. Moreover, because the scheme Is based on 
file names it probably can be used with any future file 
sharing mechanism which can access files using file 
names. In addition, my file naming convention may be 
used to provide access to Mac resource fork, OS/2 20 
extended attributes, etc., from operating systems that 
do not support the particular mechanisms to access 
those streams. Finally, the present invention may be 
utilized with any operating system which supports a 
file system accessible using file names. 25 

What has been described is merely illustrative of 
the application of the principles of the present inven- 
tion. Other arrangements and methods can be imple- 
mented by those skilled in the art without departing 
from the spirit and scope of the present Invention. 30 



Claims 

1. A ffle system apparatus for enabling access to 35 
data or characteristics of data of prevtously stored 
files characterized by 

means for parsing a file name received as 
part of a file access request into a base name 
segment and one or more appended segments, 40 

means for searching saki file system using 
sakl base name segment to select a desired file, 
and 

means for accessing a data stream asso- 
ciated with said desired base name file, said data 45 
stream selected using at least one of said ap- 
pended segments. 

2. The apparatus of daim 1 wherein at least one of 
said appended segments is a pref b( of said base so 
name. 

3. The apparatus of claim 1 wherein said at least 
one of said appended segments is a suffix of said 
base name. 55 

4. The apparatus of claim 1 wherein said base name 
file a data file and wherein said accessed data 



stream is a Macintosh resource fork. 

5. The apparatus of claim 1 wherein at least one of 
said appended segments Is used to identify a file 
attribute which is to be accessed firom one or 
more of said stored files. 

6. The apparatus of daim 1 wherein said base name 
file is identified using non-substring-based criter- 
ia. 

7. The apparatus of claim 1 wherein at least one of 
said appended segments is used to access, as a 
file, an attribute of one or more of said stored 
files. 

8. The apparahjs of claim 1 wherein 

said base name file is a data file and 
wherein 

at least one of said appended segments is 
used to access an operating system which is to be 
utilized for processing said data file. 

9. The apparatus of daim 1 wherein said base name 
segment indudes a first set of one or more char- 
acters which provides a direct memory address to 
locate a desired file in a memory means associ- 
ated with said apparatus. 

10. The apparatus of daim 1 wherein said base name 
segment accesses a group of stored fifes and 
wherein 

said base name segment further indudes 
a second set of one or more characters to identify 
which one of said group of files should be ao 
cessed. 

11. The apparatus of claim 1 wherein said file system 
operates under a UNIX operating system. 

12. A method of operating a file system apparatus to 
obtaindata or characteristics of data of previously 
stored files characterized by the steps of 

parsing a file name receh/ed as part of a 
file access request into a base name segment 
and one or more appended segments, 

searching said file system using said base 
name segment to select a desired file, and 

accessing a data stream associated with 
said desired base name file, said data stream se- 
lected using at least one of said appended seg- 
ments. 
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